I'm sympathetic to the idea that we should let main() be optionally typed as fn() -> i32, but even if we decided to do that, we'd still have a use for std::process::exit().

👍, although I find it mildly odd to put this in std::process, because everything else in that module is for dealing with child processes, not for dealing with the current process. That said, std::env::exit() would also be slightly odd, and I can't think of any other better place, so I guess std::process is fine.

but even if we decided to do that, we'd still have a use for std::process::exit()

This is a good point, and I feel the same way! I'll add some text related to this in the RFC.

I find it mildly odd to put this in std::process, because everything else in that module is for dealing with child processes, not for dealing with the current process.

Our plan is to expand the module to also allow inspection of remote processes, sending signals, etc. In that sense it may not always be specifically about child processes. I also consider process::exit along the lines of thread::sleep where the top level functions are affecting the current process or current thread.

yes please

Since we’re adding a function for this (yay), we should also guarantee at_exit-registered functions are executed.

EDIT: std::rt::at_exit, of course.
EDIT 2: sigh, this is what I get by not reading the full RFC before commenting…

@nagisa yeah I'm not quite sure how to word the documentation given that rt::at_exit is #[unstable] right now. For now I don't think we buy much providing a hard guarantee that those closures are run (due to it not mattering to otherwise-stable code). I do think, however, that this should definitely play into the stabilization of std::rt::at_exit!

Hmm, there's another major motivation for this that I can think of, which is ending the process without risking unwinding across an FFI boundary, e.g. in a Rust function that has been passed to a C library as a callback.

IIRC, unwinding past an FFI boundary is undefined behavior, but we don't have a very solid recommendation for what you should actually do if you need to terminate the process and a foreign function is (or may be) on the stack. About the only thing that you can do to prevent this right now is either call the libc::exit, or maybe try to stop the unwinding by triggering a double panic in a destructor in code nearest to the FFI?

Edit: I guess that the RFC obliquely mentions this. I guess my point is that this would be a reasonable justification for having an exit in std somewhere even if the exit code wasn't an issue. Unrelatedly, I also thought that putting it in process was a bit odd. I guess I would have expected it in env, since process contains more stuff related to IPC, whereas operations related to the current process are in env (e.g. set_var and set_current_dir).

This was discussed at today's meeting which echoed the support found on this RFC thread. This API is clearly important to provide in some form, and there's little question as to its API. Landing it now will make it possible to yield an exit code without having to stabilize the problematic set_exit_code.

Tracking issue